[レポート] Lookerセッション：データの準備を整える – Looker: BEACON Japan 2020 #BeaconJapan

「カスタマーストーリー」を支えるツール特集

#ビッグデータ

#ビジネス・アナリティクス

#ビジネス

#Looker

しんや

2020.09.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Looker社によるロードマップ、顧客事例、パートナー企業によるセッションが堪能出来るデジタルイベント『BEACON Japan 2020』が2020年09月03日から2020年09月24日までの毎週木曜日、計4日間に渡り開催されています。

当エントリでは、その中から2020年09月10日に発表された「Lookerセッション：データの準備を整える」のレポートをお届けします。

セッション概要

公式ページで紹介されているセッションの概要情報は以下の通りです。

Lookerセッション：データの準備を整える

登壇者：
・川窪善人 - Looker 事業本部カスタマーエンジニア, グーグル・クラウド・ジャパン合同会社

発表内容：
変化するテクノロジーや働き方に対して日々の業務やワークフローも柔軟に適応することが求められます。本セッションではこれからのデータ活用に対する考え方についてご紹介します。

セッションレポート

ここからは、当日に公開されたセッションの内容についてレポートします。

イベントのセッション動画については下記リンクにてアクセス可能です。

BEACON 2020: Digital Series - Japan

はじめに

このセッションでは、組織でデータを使ってより早く、大きな価値を得るために最新型のデータスタックやデータモデルを使ってどの様に改善すれば良いかを説明していきます。

改善点を理解するにあたって3つの観点があります。『データ準備における一般的な課題の確認』『最新型データスタックへのデータ登録手順の策定』『データのモデリングと変換』です。

「データの準備が整っていない」とは

お客様が分析能力を強化しようとする時には総じて『データの準備が整っていない』という事の方が多いのではないでしょうか。そして、何を以て『整った』と言えるのでしょうか。DWHが稼働し、データが安全に格納されていれば良いのでしょうか。これは我々(Looker)が考えている条件とは異なります。我々の考える『条件』とは以下の内容となります。

上記4点がなぜ必要なのか、データ分析時の一般的な問題を例にとって説明します。

『可用性』については、この条件を満たす"アップロード"が出来るまで待つ必要があり、大きなタイムロスが発生します。『品質』については、トランザクションが切り捨てられることでデータが欠落したり、正しい形式では無い情報が入ってくる事が想定されます。『集計』では、例えばIoTデータでは集計単位によっては何十億件にのぼるというケースもありえます。生データそのままでは集計に時間が掛かりますし、かといって集計単位が大きすぎると深堀りな分析を行いたくても成す術がありません。『ガバナンス』では、組織横断的にデータを集計しなければならない状況になったときに、集計に用いた計算式が組織全体で統制されたものである、という保証はあるといえるでしょうか。

以上のことから、この4つの観点を踏まえてデータを整備する事が重要となってきます。

抽出/読み込みの重要な4つのコンポーネント

重要なのは以下4つのコンポーネントです。

APIを使ってアプリケーションに接続し、データをウェアハウスに移動出来る安全でスケーラブルなプラットフォーム
数週間や数ヶ月ではなく、数時間・数日といった期間で実装が可能
データの手動アップロード／カスタム作成したスクリプト／失敗したジョブというボトルネックを取り除く仕組み
「抽出-変換-読み込み(ETL)」では無く「抽出-読み込み」を経て変換出来る(ELT)仕組み

データ変換

このフェーズでは、データ利用者のニーズを満たすためにデータを調整出来ることが必要となります。

データを「入ってくる時に途中で加工」するのではなく、トランザクションデータをDWH内で変換することで、ユーザーとアプリケーションに最適な"クエリエクスペリエンス"を作成する際の柔軟性を高めることが出来ます。想定される変換のユースケースは以下のようなものが挙げられます。

顧客別のライフタイム支出を計算
大規模/複雑なテーブルの事前計算結合
週/月/四半期ごとのサマリーテーブルを作成
追跡データからユーザーの行動をシーケンス化してセッション化

データのモデリングとガバナンス

このフェーズでは、下流工程のユーザーとアプリケーションがデータをやり取りする方法を標準化することが重要です。

データモデルの概念をウェアハウスのデータ構造と切り離してとらえる
主要なメトリクスの定義を標準化し、テストし、再検討する
エンドユーザーは、自分が「信頼できる単一の情報源」に基づいて作業していることを確信
API主導の統一されたデータアクセス手法がアプリケーションに備わる

データのモデリングと変換

もう少し詳しく、論理データモデルが必要な理由について説明します。

そもそもデータベースに統合されたモデルには、データモデルがデータベースの構造に押し込められているという問題があります。データベース統合モデルにてデータを変更しようとすると、下流へのデータフローを崩してしまう恐れがあります。論理データモデルがあれば、あるシステムが別のシステムに置き換えられたとしても論理モデルでその変更点を吸収出来ることが多く、データソースや構造の変更による影響を最小限に抑えられます。

モデリングが出来ることによって、どのようにしてデータの準備と価値実現までに掛かる時間が短縮されるかを見ていきます。

例えば、販売データの可視化を構築する際に一連の標準的なクエリや関連するコンテンツをデータモデルを使って作成したとします。もし数値が正しく無く、データ品質の問題調査が必要となった場合にも、データモデルを見れば追求・調査が可能です。問題の根本的な原因を探り、期待値に応えるための対策を検証するとします。データモデルがあれば、モデルの修正やテストといった検証作業を手軽に行なえます。それを見れば、上流工程を直すべきなのか、単純にデータモデルを修正するだけで良いのかを短時間で判断出来ます。

ETLの問題は、新しいデータ変換が必要となる度に実装する必要があり、その作業に時間が掛かってしまうことです。前もって必要なデータ変換を全て揃えられれば良いのですが、組織全体のデータの利用ケースを網羅的に把握することは不可能であり、変換が必要となる度に実装するしかありません。一方DWH内での変換処理であれば、そういった心配は無くなります。迅速かつ柔軟に新しい利用ケースに対応出来ます。従来のETLで利用ケースに合わせたデータ変換を対応するよりも、他の分析や部署に影響を与えることなく、短時間で変換処理を実装出来ます。その結果生産性が向上し、価値実現までの時間を短縮出来ます。